Compiler optimization based on collectivity analysis

ABSTRACT

An embodiment is directed to determining, by a compiler, that a call to a named barrier is matched across all of a plurality of threads, and based at least in part on determining that the call to the named barrier is matched across all of the plurality of threads, replacing, by the compiler, the named barrier with an unnamed barrier.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

This invention was made with Government support under Contract NumberHR0011-07-9-0002 awarded by DARPA (Defense Advanced Research ProjectsAgency). The Government has certain rights to this invention.

BACKGROUND

Barrier is a synchronization mechanism in Unified Parallel C (UPC),where UPC is a programming language derived from the C programminglanguage. In UPC, when a thread encounters a barrier, the thread waitsat the barrier until all other threads execute the same (or another)barrier statement. Since barriers are used extensively in UPC programs,the runtime performance associated with the execution of a barrierstatement has a significant impact on the runtime performance of typicalUPC programs.

BRIEF SUMMARY

An embodiment is directed to a method for optimizing a barriercomprising determining, by a compiler, that a call to a named barrier ismatched across all of a plurality of threads, and based at least in parton determining that the call to the named barrier is matched across allof the plurality of threads, replacing, by the compiler, the namedbarrier with an unnamed barrier.

An embodiment is directed to a computer program product comprising acomputer readable storage medium having computer readable program codestored thereon that, when executed by a compiler, performs a method foroptimizing a barrier, the method comprising determining that a call to anamed barrier is matched across all of a plurality of threads, and basedat least in part on determining that the call to the named barrier ismatched across all of the plurality of threads, replacing the namedbarrier with an unnamed barrier.

An embodiment is directed to a system comprising a compiler configuredto determine that a call to a named barrier is matched across all of aplurality of threads, and based at least in part on determining that thecall to the named barrier is matched across all of the plurality ofthreads, replace the named barrier with an unnamed barrier.

Additional features and advantages are realized through the techniquesof the present invention. Other embodiments and aspects of the inventionare described in detail herein and are considered a part of the claimedinvention. For a better understanding of the invention with theadvantages and the features, refer to the description and to thedrawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The subject matter which is regarded as the invention is particularlypointed out and distinctly claimed in the claims at the conclusion ofthe specification. The foregoing and other features, and advantages ofthe invention are apparent from the following detailed description takenin conjunction with the accompanying drawings in which:

FIG. 1 depicts an exemplary system architecture in accordance with oneor more embodiments;

FIG. 2 depicts exemplary code in accordance with one or moreembodiments;

FIG. 3A depicts exemplary code in accordance with one or moreembodiments;

FIG. 3B depicts exemplary code in accordance with one or moreembodiments; and

FIG. 4 depicts a flow chart of an exemplary method in accordance withone or more embodiments.

DETAILED DESCRIPTION

In accordance with various embodiments of the disclosure, an analysismay be performed to determine whether a program statement is executed bya plurality of threads consistently. In some embodiments, a namedbarrier may be replaced by an unnamed barrier based on the analysis. Insome embodiments, an analysis may be performed to determine whether acall to a named barrier is matched across a plurality of threads, suchthat a determination may be made as to whether an expression is the sameacross the threads. When the expression is the same, a barrier statementincluding the expression may be replaced by an unnamed barrier.

It is noted that various connections are set forth between elements inthe following description and in the drawings (the contents of which areincluded in this disclosure by way of reference). It is noted that theseconnections in general and, unless specified otherwise, may be direct orindirect and that this specification is not intended to be limiting inthis respect.

Referring to FIG. 1, an exemplary system architecture 100 is shown. Thearchitecture 100 is shown as including a memory 102. The memory 102 maystore executable instructions. The executable instructions may be storedor organized in any manner. As an example, at least a portion of theinstructions are shown in FIG. 1 as being associated with a first thread104 a and a second thread 104 b, although any number of threads may beincluded. The instructions stored in the memory 102 may be executed byone or more processors, such as a processor 106.

The threads 104 a and 104 b may be associated with a resource 108. Forexample, the resource 108 may include data, which may be organized asone or more blocks, objects, fields, or the like. The threads 104 a and104 b may access the resource 108 concurrently (e.g., concurrently interms of time or space), such that the resource 108 may be, or include,a shared resource.

In some embodiments, access to the resource 108 may be synchronized. Forexample, in a parallel computing environment, synchronization may beneeded to ensure consistency in terms of data or values when the thread104 a engages in a store or write operation with respect to a variableand the thread 104 b engages in a read operation of that same variable.Barrier statements may be used to achieve such synchronization.

The Unified Parallel C (UPC) language provides two basic types ofbarrier statements As used herein, a “named barrier” may take the form:

upc_barrier x;

where x is an expression with type int.

As used herein, an “unnamed barrier” may take the form:

upc_barrier;

Thus, relative to a named barrier, an unnamed barrier does not includean expression. In some instances, named barriers may be used by aprogrammer during development, debugging, or troubleshooting activities.The named barrier may then be replaced with an unnamed barrier followingsuch activity.

One or more embodiments may incorporate principles of a synchronizationphase. A synchronization phase may include all the program statementsbetween the completion of a upc_barrier and the start of the next.

The UPC specification requires an interrupt, in an implementationdefined manner (e.g., a diagnostic message) when the value of theexpression supplied to a named barrier differs from the value of theexpression supplied to a named barrier by any thread in the currentsynchronization phase. The UPC specification also provides that anunnamed barrier matches any other barrier invocation.

To satisfy the foregoing UPC specification requirement, a UPC runtimelibrary might need to check each barrier invocation to determine whethera barrier expression, if supplied, is the same across the invocation ofthe barrier by any thread. Such a check adds runtime overhead.

In practice, the majority of barrier statements in a UPC program may beunnamed barriers. Given that unnamed barriers match any other barrierstatement, if a compiler can prove or determine that: (1) named barriersare matched and (2) for each execution of a barrier that all threadsexecuted the same number of barrier invocations, an unnamed barrier oran optimized barrier can be used in place of a named barrier or genericbarrier, which may save computing resources (e.g., processing resources)at runtime. The second condition described above (that for eachexecution of a barrier that all threads executed the same number ofbarrier invocations) may be used to ensure that a barrier is executed byall threads in a synchronous manner.

In some embodiments, a determination may be made whether a upc_barrierinvocation at a particular program point can be safely implemented usinga specialized runtime call. In order to provide such an implementation,confirmation is needed that all prior barrier invocations are complete,and that all the barrier invocations in the current synchronizationphase are either: (1) unnamed barriers, or (2) named barriers with thesame expression value. These conditions allow the compiler to prove thatthe runtime logic used to determine whether a diagnostic message needsto be emitted is unnecessary.

In order to facilitate the compiler's analysis of a program (which maybe referred to herein as a “collectivity analysis”), a control flowgraph (CFG) may be used. A CFG may correspond to a directed graph with“nodes” and “edges,” where a node may correspond to a program statementand an edge may correspond to program flow between statements.

As part of the collectivity analysis, a collectivity property may beused. The collectivity property may identify whether a statement isexecuted, or a CFG edge is entered, by all threads the same number oftimes. The collectivity property may be used to prove the legality of acode optimization, such as replacing a generic barrier call with anoptimized barrier version that has a lower latency.

The collectivity analysis may be implemented across procedure calls(e.g., as an inter-procedural analysis) since the “main” function mayalways be entered by all threads consistently and may therefore serve asa starting point of the analysis. The collectivity analysis may beimplemented as an intra-procedural analysis, where certain collectivityproperties or information may be provided by compiler options orpragmas.

A statement or a CFG edge may be deemed as being “executed by allthreads consistently” if, and only if, the following two conditions aresatisfied: (1) the statement or the CFG edge is entered by all threadsfor the same number of times, and (2) before each entering of thestatement or the CFG edge, all threads have executed the same number ofbarriers.

Assumptions may be made to facilitate the collectivity analysis. Forexample, a function under analysis may be assumed to be entered by allthreads consistently. A CFG may be constructed for the function anddominators and post-dominators of each CFG node may be known. Statementsof the function may be stored in, e.g., a linked list so that given afirst statement the next statement after the first statement can befound or located. The CFG nodes may be indexed and the index may startwith, e.g., one (1).

Collectivity properties for all the other functions may be known, suchas whether a particular function is entered by all threads consistentlyand exited by all threads consistently. Such information could beobtained through an inter-procedural analysis, or by compiler commandline options or pragmas. If a function corresponds to a standard Clibrary function or a UPC library function, a compiler option may begiven to assure that a function with the same name as a standard Clibrary function or UPC library function is truly a standard C libraryfunction or UPC library function, such that its internal semantics andtheir effect on collectivity properties may be known in advance.

To facilitate the collectivity analysis, a structure (which may bereferred to herein as “CollectivityInfo”) may be used to representcollectivity information about a statement or a CFG edge which containsthe following members or elements: (1) execByAll, (2) lastNodeByAll, and(3) barriersSinceLast.

execByAll may correspond to a parameter or flag that may indicatewhether a statement or CFG edge is entered by all threads consistently.A value of, e.g., ‘1’ may indicate that the statement or CFG edge isentered by all threads consistently and a value of ‘0’ may indicateotherwise.

lastNodeByAll may correspond to an index for the last CFG node which isexited by all threads consistently before entering this statement or CFGedge. A value of, e.g., ‘0’ may indicate that such a node does notexist. A value other than ‘0’, such as a positive value, may indicatethat the corresponding CFG node is exited by all threads consistently,and all the paths from that CFG node to a current CFG node or CFG edgecontain the same number of barriers.

barriersSinceLast may correspond to a value (e.g., an integer value)equal to the number of barriers contained in the paths from the CFG nodewith index lastNodeByAll to the current CFG node or edge, iflastNodeByAll is not ‘0’.

In some embodiments, two types of tables (e.g., two hash tables) may becreated for the collectivity analysis. A first of the tables may be usedto map a statement to collectivity information and a second of thetables may be used to map a CFG edge to collectivity information. Pseudocode is provided in FIG. 2. The first four lines of code (lines 1-4) inFIG. 2 may serve to initialize the tables or maps. Lines 5-10,corresponding to a loop such as a while lop, may serve to propagatecollectivity information across the CFG until no changes to thecollectivity information are present or detected.

FIGS. 3A-3B (collectively referred to herein as FIG. 3) illustrate aprocedure that may be used to update the statement map and CFG map foreach statement. As shown, the procedure of FIG. 3 may implement thecollectivity analysis by checking for various conditions that are thesubject of the “if” and “else if” tests or checks provided therein.

The code illustrated in FIGS. 2 and 3 is illustrative. In someembodiments, an actual implementation of the code may differ from whatis shown. In some embodiments, some of the code may be optional orexecute in an order or sequence different from what is shown. In someembodiments, additional code not shown may be included.

FIG. 4 illustrates a flow chart of a method that may be used inaccordance with one or more embodiments. The method may be used orexecuted by a compiler to determine when a named barrier can be replacedby an unnamed barrier that does not require a semantic check at runtime.

In block 402, a determination may be made whether a statement isexecuted, or a CFG edge is entered, by all threads the same number oftimes. If not, flow may proceed along the “False” path out of block 402to “End” 408, such that the named barrier may be retained. Otherwise, ifthe statement is executed, or the CFG edge is entered, by all threadsthe same number of times flow may proceed along the “True” path out ofblock 402 to block 404.

In block 404, a determination may be made, for each execution of abarrier, whether all threads have executed the same number of barrierinvocations. If not, flow may proceed along the “False” path out ofblock 404 to “End” 408, such that the named barrier may be retained.Otherwise, flow may proceed along the “True” path out of block 404 toblock 406.

In block 406, a named barrier may be replaced with an unnamed barrier,given that both tests or checks associated with blocks 402 and 404returned a “True” result.

The method of FIG. 4 is illustrative. In some embodiments, one or moreof the blocks or operations may be optional. In some embodiments, one ormore additional operations not shown may be included. In someembodiments, the operation may execute in an order or sequence differentfrom what is shown in FIG. 4.

Aspects of the disclosure may be implemented independent of a specificinstruction set (e.g., CPU instruction set architecture), operatingsystem, or programming language. Aspects of the disclosure may beimplemented in conjunction with non-transactional machine instructions.Aspects of the disclosure may be implemented in connection withthread-level speculation, which may be similar to HTM.

In some embodiments various functions or acts may take place at a givenlocation and/or in connection with the operation of one or moreapparatuses or systems. In some embodiments, a portion of a givenfunction or act may be performed at a first device or location, and theremainder of the function or act may be performed at one or moreadditional devices or locations.

As will be appreciated by one skilled in the art, aspects of thisdisclosure may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present disclosure make take theform of an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiments combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the disclosure may take the form of a computerprogram product embodied in one or more computer readable medium(s)having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific example (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent disclosure may be written in any combination of one or moreprogramming language, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming language, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

In some embodiments, an apparatus or system may comprise at least oneprocessor, and memory storing instructions that, when executed by the atleast one processor, cause the apparatus or system to perform one ormore methodological acts as described herein. In some embodiments, thememory may store data, such as one or more data structures, metadata,etc.

Embodiments of the disclosure may be tied to particular machines. Forexample, in some embodiments one or more devices may allocate or manageresources, such as HTM resources. In some embodiments, the one or moredevices may include a computing device, such as a personal computer, alaptop computer, a mobile device (e.g., a smartphones), a server, etc.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the disclosure.As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, element components,and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present disclosure has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the form disclosed. Many modifications and variations will beapparent to those of ordinary skill in the art without departing fromthe scope and spirit of the disclosure. The embodiments were chosen anddescribed in order to best explain the principles of the disclosure andthe practical application, and to enable others of ordinary skill in theart to understand the disclosure for various embodiments with variousmodifications as are suited to the particular use contemplated.

The diagrams depicted herein are illustrative. There may be manyvariations to the diagram or the steps (or operations) described thereinwithout departing from the spirit of the disclosure. For instance, thesteps may be performed in a differing order or steps may be added,deleted or modified. All of these variations are considered a part ofthe disclosure.

It will be understood that those skilled in the art, both now and in thefuture, may make various improvements and enhancements which fall withinthe scope of the claims which follow.

What is claimed is:
 1. A method for optimizing a barrier comprising:determining, by a compiler, that a call to a named barrier is matchedacross all of a plurality of threads; and based at least in part ondetermining that the call to the named barrier is matched across all ofthe plurality of threads, replacing, by the compiler, the named barrierwith an unnamed barrier.
 2. The method of claim 1, further comprising:determining, by the compiler, that the named barrier is executed by allof the plurality of threads consistently.
 3. The method of claim 2,wherein determining that the named barrier is executed by all of theplurality of threads consistently comprises: determining, by thecompiler, that the named barrier is entered by all of the plurality ofthreads the same number of times; and determining, by the compiler, thatall of the plurality of threads have executed the same number ofbarriers before entering the named barrier.
 4. The method of claim 1,wherein the named barrier and the unnamed barrier are associated with aUnified Parallel C (UPC) program.
 5. The method of claim 4, furthercomprising: executing, by a plurality of parallel computing devices, theUPC program.
 6. A computer program product comprising a computerreadable storage medium having computer readable program code storedthereon that, when executed by a compiler, performs a method foroptimizing a barrier, the method comprising: determining that a call toa named barrier is matched across all of a plurality of threads; andbased at least in part on determining that the call to the named barrieris matched across all of the plurality of threads, replacing the namedbarrier with an unnamed barrier.
 7. The computer program product ofclaim 6, wherein the method further comprises: determining that thenamed barrier is executed by all of the plurality of threadsconsistently.
 8. The computer program product of claim 7, whereindetermining that the named barrier is executed by all of the pluralityof threads consistently comprises: determining that the named barrier isentered by all of the plurality of threads the same number of times; anddetermining that all of the plurality of threads have executed the samenumber of barriers before entering the named barrier.
 9. The computerprogram product of claim 6, wherein the named barrier and the unnamedbarrier are associated with a Unified Parallel C (UPC) program.
 10. Thecomputer program product of claim 6, wherein determining that the callto the named barrier is matched across all of the plurality of threadscomprises determining that an expression included in the named barrieris common across all of the plurality of threads.
 11. A systemcomprising: a compiler configured to: determine that a call to a namedbarrier is matched across all of a plurality of threads; and based atleast in part on determining that the call to the named barrier ismatched across all of the plurality of threads, replace the namedbarrier with an unnamed barrier.
 12. The system of claim 11, wherein thecompiler is configured to: determine that the named barrier is executedby all of the plurality of threads consistently.
 13. The system of claim12, wherein the compiler is configured to: determine that the namedbarrier is executed by all of the plurality of threads consistently by:determining that the named barrier is entered by all of the plurality ofthreads the same number of times; and determining that all of theplurality of threads have executed the same number of barriers beforeentering the named barrier.
 14. The system of claim 11, wherein thenamed barrier and the unnamed barrier are associated with a UnifiedParallel C (UPC) program.
 15. The system of claim 14, furthercomprising: a plurality of parallel computing devices configured toexecute the UPC program.
 16. The system of claim 11, wherein thecompiler is configured to: determine that the call to the named barrieris matched across all of a plurality of threads by determining that anexpression of an integer type included in the named barrier is commonacross all of the plurality of threads.